1. Field of the Invention
The invention relates to virtualization techniques and to resource management.
2. Background Art
A server computer, workstation, desktop computer, or any other computing platform has a plurality of physical resources that are used to provide services. These physical resource may include, for example, processors, memory, and other hardware resources. The computing platform uses the available physical resources to handle a plurality of workloads. In general, a workload is a set of related processes. Resource management is the controlling of resources and the allocation of resources among workloads on the computing platform.
One existing approach to resource management is implemented in the SOLARIS operating system from Sun Microsystems, Inc., Santa Clara, Calif. One way that the SOLARIS operating system manages resources is by using the concepts of projects, tasks, and resource controls.
The project and task entities are used to describe workloads. A task is a group of processes. A task is associated with a project. A project may include multiple tasks. The system maintains a project database. The project database maintains information about the projects on the system. Among other information, the entry for a particular project in the project database may include one or more project attributes. Project attributes may be used to set values for resource controls.
The SOLARIS operating system implements a resource control framework to implement resource controls. The resource control framework manages resource controls on processes, tasks, and projects. These resource controls are enforced by the kernel. Further, the resource control framework leverages the project database such that resource controls for a process, task, or project may be set in the project database. The existing implementation of the resource control framework may be leveraged by various SOLARIS operating system facilities. In general, the SOLARIS operating system resource control framework provides advanced, kernel-enforced resource control capabilities in a known fashion.
The SOLARIS operating system also provides a resource capping daemon that enables regulation of physical memory consumption by processes running in projects that have resource caps defined. In more detail, a resource cap is an upper bound placed on the consumption of a resource, such as physical memory. The existing resource capping daemon and associated utilities support per-project physical memory caps. Resource caps can be defined using attributes of project entries in the project database. Resource caps are asynchronously enforced at the user level by the resource capping daemon. The resource capping daemon periodically samples the resource utilization of projects that have physical memory caps. When the system's physical memory utilization exceeds the threshold for cap enforcement, and other conditions are met, the daemon takes action to reduce the resource consumption of projects with memory caps to levels at or below the caps. The resource capping daemon manages physical memory by regulating the size of a project workload's resident set (memory pages resident in physical memory) relative to the size of the project workload's working set (memory pages that the workload actively uses during its processing cycle).
Further, the resource capping daemon also supports various configuration options including the ability to configure the threshold for cap enforcement. The threshold for cap enforcement is the percentage of physical memory utilization on the system that triggers cap enforcement. The resource capping daemon periodically performs various operations. The intervals for these operations may be configured. For example, the resource capping daemon periodically samples the resident set size of projects that have physical memory caps (that are defined using attributes in the project database). This sampling interval is a configurable value. The resource capping daemon and associated utilities also support the monitoring of the resource utilization of capped projects.
Another way that the SOLARIS operating system manages resources is with SOLARIS Containers, which is an operating system virtualization technique. The use of virtualization is increasing. In general, virtualization relates to creating an abstraction layer between software applications and physical resources. There are many approaches to virtualization.
SOLARIS Containers includes several different technologies that are used together to consolidate servers and applications. With server virtualization, applications can be consolidated onto a fewer number of servers. For example, multiple virtual servers may exist on a single physical server.
The SOLARIS Containers approach to implementing virtualization involves a technology referred to as SOLARIS zones and a technology referred to as SOLARIS resource pools. Zones are separate environments on a machine that logically isolate applications from each other. Each application receives a dedicated namespace. Put another way, a zone is a type of sandbox. A resource pool is a set of physical resources such as, for example, processors. The SOLARIS pools facility is used to partition the system resources into a plurality of resource pools for the purposes of resource management. The SOLARIS zones facility is for virtualizing the operating system to improve security, provide isolation and administrative delegation.
When consolidating applications with SOLARIS Containers, physical resources are partitioned into a number of resource pools. A zone may be created for each application, and then one or more zones are assigned to each resource pool.
Another technology involved in SOLARIS Containers is called the Fair Share Scheduler (FSS). The Fair Share Scheduler is used when multiple zones are assigned to the same resource pool. The scheduler software enables resources in a resource pool to be allocated proportionally to applications, that is, to the zones that share the same resource pool.
In an existing implementation of SOLARIS Containers, the pools facility is static. That is, the pool configurations must be defined in advance. However, SOLARIS zones are dynamic. There can be many zones defined; the zones may not all be running at a particular time. Zones can be rebooted or even moved to a new host.
In the SOLARIS Containers approach to virtualization, zones and resource pools provide application containment. Within an application container, the application believes that it is running on its own server; however, the kernel and a number of system libraries are shared between the various containers. As well, the physical resources are shared in accordance with the configured resource pools.
FIGS. 1-3 illustrate an existing implementation of SOLARIS Containers, showing how virtualization allows multiple applications and servers to be consolidated onto a single physical server using application containers composed of zones and resource pools. As shown in FIG. 1, a single physical server 10, using server virtualization, allows the consolidation of an email application 12, a first web server 14, and a second web server 16. The single physical server 10 includes multiple virtual servers such that, after consolidation, each of the email application, first web server, and second web server exists on its own virtual server on server 10.
As best shown in FIG. 2, in order to create the application containers, each application has its own zone 22, 24, and 26. FIG. 3 illustrates the completed example including first and second resource pools 30 and 32, respectively. Zones 22, 24, and 26 are non-global zones; the global zone is indicated at 34. Global zone 34 is the original SOLARIS operating system instance.
With continuing reference to FIG. 3, zone 22 has a dedicated resource pool, pool 32. Zone 24, zone 26, and the global zone 34 share resource pool 30. The Fair Share Scheduler (FSS) proportionally allocates resources to zone 24, zone 26, and global zone 34 in accordance with assigned numbers of shares.
As shown, there are four application containers. The first container is composed of zone 22 and resource pool 32. The second container is composed of zone 24 and resource pool 30. The third container is composed of zone 26 and resource pool 30. The fourth container is composed of global zone 34 and resource pool 30.
Background information relating to SOLARIS Containers technology may be found in Joost Pronk van Hoogeveen and Paul Steeves, Solaris Software, “SOLARIS 10 How To Guides: Consolidating Servers and Applications with SOLARIS Containers,” 2005, Sun Microsystems, Inc., Santa Clara, Calif.
Further background information may be found in “System Administration Guide: Solaris Containers-Resource Management and Solaris Zones,” Part No.: 817-1592, 2006, Sun Microsystems, Inc., Santa Clara, Calif.
Another existing approach to virtualization involves what are referred to as virtual machines. In this approach to virtualization, software running on the host operating system (or in some cases below the host operating system) allows one or more guest operating systems to run on top of the same physical hardware at the same time. In this approach, the guest operating system is a full operating system, including the kernel and libraries.
Further, in an existing implementation of SOLARIS Containers, it is possible for one zone to either accidentally or deliberately consume most of the physical memory on the system, thereby negatively impacting the rest of the system. The existing resource capping daemon provided by the SOLARIS operating system does enable regulation of physical memory consumption by processes running in projects that have resource caps defined. However, in the case of zones, this is of limited utility because an instance of the resource capping daemon must run inside each zone. Running an instance of the resource capping daemon inside each zone is useful in some situations. There are also situations where this approach is ineffective such as, for example, when the zone administrator is untrusted. An untrusted zone administrator could circumvent the resource capping by changing the resource cap, violating the containment. In addition to the requirement that an instance of the resource capping daemon must run inside each zone, within a particular zone, all of the zone processes must run within a specified project in the zone with the specified project having a defined physical memory cap. This approach to physical memory capping, in addition to being insecure and easily circumvented, is complex and error prone to configure.
For the foregoing reasons, there is a need for an improved approach to physical memory capping for use in virtualization.